VERSION WITH MARKINGS TO SHOW CHANGES MADE 

In the specification: 

I. In the Brief Description of the Figures, after the first paragraph on 
page 66, lines 1-3, please add the following paragraphs: 

-FIG. 31 is an exemplary user interface U100 in which a buyer enters a 
description of the product or service she wants to purchase. 

FIG. 32 is an exemplary user interface U200 that displays research or advice 
requested by a buyer. 

FIG. 33 is an exemplary user interface U300 that displays a buyer's priorities for 
product or service features. 

FIG. 34 is an exemplary user interface U310 that lets a buyer choose the level of 
expert assistance provided to the buyer. 

FIG. 35 is an exemplary user interface U400 that lets a buyer constrain her search. 

FIG. 36 is another exemplary user interface U410 that lets a buyer constrain her 

search. 

FIG. 37 is an exemplary user interface U500 that lets a buyer create an automated 

bot. 

FIG. 38 is an exemplary user interface U600 that displays initial seller offers to a 

buyer. 
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FIG. 39 is an exemplary user interface U700 that displays value scores for seller 

offers. 

FIG. 40 is an exemplary user interface U800 with a buyer registration form. 

FIG. 41 is an exemplary user interface U810 that lets a buyer limit the number of 
seller offers displayed to the buyer. 

FIG. 42 is an exemplary user interface U900 that displays a list of final adjusted 
offers along with a score for each offer. 

FIG. 43 is an exemplary user interface U910 that includes value added products or 
services or other offers to enhance the overall offering to the buyer. 

FIG. 44 is an exemplary user interface U1000 that lets a buyer execute a 
transaction. 

FIG. 45 is an exemplary user interface U1100 that shows an adjusted offer 
evaluated with respect to a buyer's priorities. 

FIG. 46 is an exemplary user interface U1200 that displays the results of a 
suggestion search. 

FIG. 47 is an exemplary user interface U1300 that lets a buyer access information 
related to the buyer that is stored in a database. 

FIG. 48 is an exemplary user interface U1310 that displays an archived record of 
a buyer's transactions. 

FIG. 49 is an exemplary user interface U1320 that shows a report of a rewards 
program for a buyer. 
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FIG. 50 is an exemplary user interface U2000 that provides an overview to a 
seller, with links to sections discussing the rights and responsibilities accepted by the 
seller. 

FIG. 51 is an exemplary user interface U2100 that illustrates possible types of 
affiliation. 

FIG. 52 is an exemplary user interface U2200 that summarizes exemplary types 
of information available under each type of affiliation. 

FIG. 53 is an exemplary user interface U2300 for specifying a seller's business 

rules. 

FIG. 54 is an exemplary user interface U2400 for specifying a seller's loyalty 
program. 

FIG. 55 is an exemplary user interface U3000 that shows information about an 
anonymous buyer that may be seen by a seller. 

FIG. 56 is another exemplary user interface U3100 that shows information about 
an anonymous buyer that may be seen by a seller. 

FIG. 57 is an exemplary user interface U3200 that shows records of posted offers 
that may be seen by a seller. 

FIG. 58 is an exemplary user interface U3400 that shows records of adjusted 
offers that may be seen by a seller. 

FIG. 59 is an exemplary user interface U3500 that displays the terms of an offer 
eventually accepted by a buyer. 
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FIG. 60 is an exemplary user interface U3600 that displays aggregate information 
about and analysis of auctions occurring during a certain time interval. - 

II. In the Detailed Description, please delete the paragraph beginning on 
page 75, line 19, and all successive paragraphs through page 96, line 7, and replace 
the deleted paragraphs with the following replacement paragraphs: 

At step 100 in FIG. 24, the buyer creates an RFO 10. In a preferred embodiment, 
video monitor A405 of buyer interface A400 displays a form similar to III 00 (FIG. 31) . 
In the form U100 (FIG. 31) , a buyer enters a description of the product or service she 
wants to purchase, the description preferably being made in natural language. The 
description may include the type of product, requested features, warranty period, 
financing needs, delivery preference, and any other attribute the buyer wishes to include. 
The description, however, can be also very general. For example, the buyer may specify 
that she is looking for products enabling her to watch movies or for products enabling her 
to store food, rather than specifying particular items like VCRs and DVD players or 
refrigerators and kitchen cabinets, respectively. The description is received by buyer web 
server A500, which passes it to natural language interpreter A1210, embedded within 
core network A1200, to convert it into a format that shopping engine A1230 can later 
process. In another embodiment, the buyer selects the product category and features from 
a pre-defined on-screen or pull down menu, which may be hierarchically structured. 

At step 150, the buyer decides whether or not she wants to request information or 
advice on a product or category of products. This may be done, for example, by clicking 
on the "learn" button in form U100 (FIG. 31) . In another implementation, information is 
displayed automatically, depending on the vagueness of the buyer's description. 
Descriptions that do not include a precise specification of a product or service, but only 
an area of interest, are treated to suggest the buyer needs to be informed about products 
or services in that area. In yet another implementation, the buyer may actually begin with 
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step 150, and proceed to step 100 only after having been educated about products fitting 
her needs. 

At step 170, video monitor A405 displays requested research or advice, through a 
form similar to U200 (FIG. 32) . The research or advice is supplied to buyer interface 
A400 by third party data server A1280, through buyer web server A500. The information 
supplied based on the research request can vary in its complexity. For example, without 
limitation, the information can be as simple as an article explaining the available features 
of new products and the differences among them or as detailed as a table summary with 
feature-by- feature product comparisons like those often shown in consumer magazines 
(e.g., Consumer Reports). Advice can range from a mere recommendation of a brand 
name, to a full stipulation of product's essential features, or to summary statistics 
showing the popularity of various products among users of the present invention. 

At step 200, the buyer can optionally delimit the scope of seller search, through a 
form such as U400 (FIG. 35) or U410 (FIG. 36) , which may be accessed by selecting the 
"look only" button on form U100 (FIG. 31) . A wide variety of constraints can be placed 
on the search. For example, the buyer can limit eligible retailers to only those within a 
local geographical area, state, or country. She can also exclude retailers from a particular 
geographical area, e.g. "everything but California". Another limit may be imposed by 
specifying the highest price the buyer is willing to pay, or the shortest period of warranty 
service. The buyer can also insist on including in the search only those retailers that were 
ever rated by reputable agencies, or reviewed by major magazines, or earned a high 
reputation from other buyers, possibly with similar demographic characteristics. The 
buyer's constraints are stored in the Buyer Database Server A1220. In an alternative 
embodiment, step 200 may be omitted. In yet another alternative embodiment, step 200 
can be embedded after step 300. 
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At step 250 the buyer may choose to proceed directly to the specification of her 
preferences and the actual auction, both of which are described later in this section. This 
may be done by clicking on the "go!" button in form U100 (FIG. 31V form U400 (FIG. 
35) , or form U410 (FIG. 36) . The choice is for convenience to repeat buyers, who are 
familiar with the interface and aware of the time saved by using this shortcut. In another 
embodiment of the system, it need not be implemented. By clicking "my choices" in 
form U410 (FIG. 36) in buyer interface A400, the buyer does not proceed directly to the 
auction, which makes the present invention comparable in "look and feel" to current 
Internet shopping engines, thereby lowering the switching costs to users. 

At step 300, shopping engine server A1230 queries product qualifier database 
server A1270, and retrieves offers that satisfy most or all of the criteria specified in RFO 
10. The results of the search, initial offers 40, are passed to buyer interface A400, where 
they are displayed in form U600 (FIG. 38) . Sellers offers may either be precompiled and 
stored on product qualifier database server A1270, or server A1230 may request them 
and compile them on the fly from seller web server A1000, direct database access method 
server A800, or HTML data interface method server A600. 

The buyer may sort returned initial posted offers 40 in U600 (FIG. 38) by price, 
delivery time, store distance, seller name, manufacturer name, model number, etc., by 
clicking on the appropriate buttons. In another embodiment, the posted offers could be 
sorted by a score that is automatically imputed to each offer, as described in greater detail 
in step 380. 

Optionally, the system could, at this stage, enrich the list of initial offers by a list 
or browser window displaying complementary goods or services. Complementary or 
substitution products may, without limitation, be identified by analysis of buying habits 
of consumers or by the application of a collaborative filter to the buyer's request. In 
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other embodiments, similar suggestions could be made, without limitation, at steps 380, 
1300, 1620, or 1900. 

At step 350 the buyer can revise her RFO 10, by displaying the form U100 (FIG. 
31) (or a similar form) again. This helps in situations in which RFO 10 was stipulated 
too narrowly, with shopping engine A1230 returning only a few or no initial offers 40, or 
too broadly, when hundreds of offers 40 were returned U600 (FIG. 38) . Alternatively, 
this step can be omitted, leaving buyers to use other methods to return to step 100, such 
as pressing the web browser's "back" button. 

At step 370, the buyer asks for a recommendation from among the initial offers 
40, for instance, by clicking on the "make a recommendation" button in form U600 (FIG. 
38) . Alternatively, the recommendation may be generated automatically, without the 
buyer's prompt, when the posted offers are initially displayed. 

At step 380, the recommendation is displayed by buyer interface A400 in a 
suitable form. A possible form is shown in U700 (FIG. 39) , wherein a numerical score is 
calculated for each initial offer 40 and offers are sorted in descending order. Such a score 
could, for example, be based in part on the ranking of the product by Consumer Report 
and/or other magazines, or it could be based in part on its popularity among other buyers, 
as determined from records of purchases. 

At step 400 buyer chooses to proceed with an auction or to make an immediate 
transaction. In one embodiment, buyers conducting immediate transactions (i.e., not 
using the auction component of the present invention) do not need to identify themselves 
because they transfer to the seller's web site to conclude the transaction, while buyers 
requesting adjusted offers 40 must be registered. In alternative embodiments, all buyers 
may be required to conclude every transaction in-situ, thus requiring identification from 
all of them. In yet another embodiment, all transactions may be concluded directly with 
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the seller, for example at his website, thus requiring no registration from any buyer at the 
Auctioneer site. 

At step 500, the System checks whether the buyer has registered with buyer web 
server A500 before. If not, a standard registration form U800 (FIG. 40) is displayed on 
buyer interface video monitor A405, in which the buyer identifies herself. This step can 
also be automated, for example by using browser cookies, thus demanding no action on 
the buyer's part. 

In the present embodiment, registration and identification are used to create and 
invoke buyer's profile, stored within buyer database server A1220. A simplified version 
of the system may not require step 500. Instead, buyers could re-enter information 
concerning their priorities every time they use the simplified system. 

At step 600, the buyer completes a registration process. Buyer web server A500 
instructs buyer database server A1220 to open a new "account", and the buyer sees, for 
example, a form such as U1300 (FIG. 47) on her monitor A405. The buyer or her proxy 
enters information about the buyer which can include, without limitation, basic personal 
demographic information, billing and shipping addresses, and credit card information, 
which are stored in buyer database A1220. The buyer's account information is preferably 
accessible to the buyer from any user interface so that it can be updated or modified by 
the buyer at any time. 

Form U1300 (FIG. 47) makes accessible other forms, like U1310 (FIG. 48) , 
U1320 (FIG. 49) , U300 (FIG. 33) , or U310 (FIG. 34) . Form U1310 (FIG. 48) displays an 
example of buyer's archive record, showing all transactions that the buyer made within 
the system. Form U1320 (FIG. 49) shows a report of a rewards program. Sellers may 
offer benefits in terms of a reward program to the buyer, as part of their bidding strategy 
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and/or in exchange for information about the buyer. Forms U300 (FIG. 33) and U310 
(FIG. 34) deal with the buyer's priorities and are discussed later in this section. 

At step 700, the buyer chooses whether to create a new set of priorities 20 or to 
use her priorities 20 stored in her account on buyer database server A1220. For example, 
buyers who frequently purchase the same or similar goods may benefit from using their 
stored priorities 20, which had already been optimized. At step 800, buyer web server 
A500 contacts buyer database A1220 to recover stored priorities 20. They are, in turn, 
passed to buyer interface A400, and displayed in a form such as U300 (FIG. 33) . The 
sliders in form U300 (FIG. 33) , which correspond to the buyer's priorities for product or 
service features, can assume their positions from the last transaction, or their positions 
when last stored in the buyer's account. 

At step 1000, buyer's approval of the recovered priorities 20 is sought. In form 
U300 (FIG. 33) , the priorities 20 may be approved by clicking on the "go!" button. At 
step 1100, the buyer modifies recovered priorities 20. This modification can be done in a 
wide variety of ways. For example, the modification can be made by adjusting the sliders 
in an exemplary form U300 (FIG. 33) . It can also be made with the aid of an expert 
system, as illustrated by the "decide for me" button on form U310 (FIG. 34) . The expert 
system may run on buyer database server A1220, or any other server within core network 
A1200, or be dedicated to its own server. The expert system may, for instance, analyze 
the buyer's transaction record and infer the most likely priorities 20 that would have 
generated such a record. It may also base its suggestion on the average or median 
priorities 20 of a group of buyers with similar demographic characteristics. 

At step 900, the buyer creates a new set of priorities 20 by moving sliders within 
form U300 (FIG. 33) . Sliders are just one example of the many ways that could be used 
to enable a buyer to set her priorities. Other methods of setting preferences are well 
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known to those of ordinary skill in the art and need not be described in detail here. 
Optionally, expert system aid may be available at step 900. 

At step 1150, buyer instructs buyer web server A500 to store the new or modified 
priorities 20 in her account within buyer database A1220. The actual storing of priorities 
20 is done in step 1175. 

At step 1180, the buyer can optionally put restrictions on displayed auction 
results. For instance, as shown in an exemplary form U810 (FIG. 41) , the buyer can limit 
the number of adjusted offers 50 to be displayed, or provide a cut-off point for adjusted 
offers 50. Buyer may also be reminded at this step of the restrictions created in step 200, 
in forms U400 (FIG. 35) and U410 (FIG. 36) . In another embodiment, step 1180 may be 
omitted. 

At step 1200, auction engine server A1250 runs a buyer's auction. The detailed 
description of the auction process is provided later below, using FIG. 28 with steps 1210 
through 1280. 

In certain cases, as in U910 (FIG. 43) , utilizing A1290, it may be beneficial for 
the Auctioneer (the buyer's auction service provider) to attach value added products or 
services or other offers which may be combined with seller offers to enhance the overall 
offering to the buyer. This may also give the perception to the buyer that all offers are 
adjusted whether or not they are from affiliated sellers. 

At step 1300, a list of final adjusted offers 50, with their scores, is returned to the 
buyer web server A500 by auction engine server A1250. It is passed to buyer interface 
A400, through an exemplary form U900 (FIG. 42) . The results may be sorted in a wide 
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variety of ways, including without limitation, by the score each adjusted offer 50 earned, 
by price, or by model number. 

At step 1400 buyer determines whether to proceed or to modify her priorities 20. 
For instance, by clicking on the "adjust my priorities" button in form U900 (FIG. 42) , the 
buyer returns to step 700. The loop gives the buyer a quick way to learn how different 
sets of priorities 20 affect the resulting adjusted offers 50. Step 1400 is not essential, 
other embodiments need not contain it. 

At step 1450, buyer may revise her RFO 10. Revision is accessible, for example, 
by pressing the "I want to .. ." button in form U900 (FIG. 42) . 

At step 1460, buyer can choose to employ an automated bot. The bot enables the 
buyer to automate recurring transactions. It can alert the buyer when the transactions are 
supposed to be undertaken and/or it can enable the buyer to search for buyer-specified 
offers that are unavailable at the present time, but which are likely to appear in the future. 
The bot may run on buyer web server A500, however, it can also run on a dedicated 
server (not displayed) within core network A1200. The choice of using an automated bot 
can also be made available to the buyer at other points in the process. 

At step 1470, buyer sets parameters for the bot, as illustrated in exemplary form 
U500 (FIG. 37) . For instance, the buyer can specify, without limitation, the length of 
time for the bot to be active, the means of notification of the buyer, or whether or not the 
transaction can be made by the bot on the buyer's behalf. 

At step 1500, the buyer can elect to see an analysis of final adjusted offers. The 
analysis is provided to help the buyer better understand the influence of priorities 20 on 
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adjusted offers 50. It may be accessible via the "explain" button in form U900 (FIG. 42) . 
or in any other suitable way. 

At step 1600, analysis of adjusted offers is performed and displayed. In one 
embodiment, buyer's monitor A405 displays exemplary form U1100 (FIG. 45) , which 
shows adjusted offer 50 evaluated with respect to buyer's priorities 20. Optionally, or in 
another embodiment, buyer web server A500 uses adjusted offers 50 and buyers priorities 
20 to compute the critical factors that made a particular offer inferior to the highest-score 
offer. Yet, in another embodiment, buyer's monitor A405 displays a table that lists all 
attributes of the adjusted offers 50, together with buyer's priorities 20, and explicitly 
shows how the scores were calculated. 

At step 1620, the buyer can request expert suggestions. The suggestions may be 
based on numerous factors, including, without limitation, results of product or service 
testing by independent third parties, recommendations of major magazines, or reputation 
points given by the other users of the present invention. It can also take the form of 
recommending a complementary product, as described earlier. For example, a buyer 
interested in a home theater system can be informed that most other people buying home 
theater systems also buy speaker stands. 

At step 1640, the actual suggestion is generated and displayed. In one 
embodiment, buyer web server A500 queries third party database server A1280 for 
results of testing, or for third party recommendations. It also queries buyer database 
server A1220 to identify other products and/or services that are commonly purchased 
with the product or service returned in adjusted offers 50. Typical results of a suggestion 
search are displayed in exemplary form U1200 (FIG. 46) on buyer's monitor A405. 

At step 1700, the buyer can make a decision to purchase. This can be done, for 
example, by clicking on a "buy me!" button in form U900 (FIG. 42) . Foregoing a 
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purchase makes buyer web server A500 store buyer's RFO 10 for potential later use. The 
buyer may alternatively click a "talk to a rep" button in form U900 (FIG. 42) to be 
connected, either telephonically or electronically to a seller representative, who could 
potentially answer questions in regards to the product or service in question. 

At step 1800, the transaction is executed. In the preferred embodiment, buyer 
web server A500 receives buyer's billing information from buyer database server A1220, 
and relays it to buyer interface A400 for confirmation. For example, form U1000 (FIG. 
44) may be shown on buyer's monitor A405, asking the buyer to either confirm or 
modify her billing and shipping information. Upon confirmation, purchase 30 is received 
by buyer web server A500 and relayed to billing server A1260 for further processing. 

Billing server A1260 sends purchase 30 to HTML data interface method server 
A600, or direct database access method server A800 (possibly utilizing a proprietary 
standard), or to seller web server A1000 depending on the seller's setup. Purchase 30 is 
then received, respectively, by seller website A700, seller database A900, or seller 
interface All 00. For example, a purchase notification mediated by seller web server 
A1000 may look like that in form U3500 (FIG. 59) . Purchase announcement 70 notifies 
the winning seller that a transaction has been made on his behalf. Also, billing server 
A1260 credits the seller's account, while applying agreed upon charges for a closed 
transaction. 

In an alternative embodiment, if users of the present invention are not required to 
register but are required to perform the transaction in-situ, then step 1900 would consist 
of the buyer inputting billing and shipping information, with the rest of the process being 
the same as that described above. 

In yet another embodiment, if buyers complete the transaction at the winning 
seller's website, then step 1900 would consist of buyer web server A500 determining 
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which seller was chosen by the buyer, and instructing billing server A1260 to charge that 
seller a success fee. 

FIG. 28 illustrates an exemplary embodiment of the process by which auction 
engine server A1250 generates adjusted offers 50. The process involves the use of 
buyer's RFO 10, her priorities 20, the sellers' business rules 60, and a set of auction rules. 
The auction rules are preferably specified by the Auctioneer service provider, but can 
also be specified by the buyer or any other appropriate party. Optionally, third party 
information can be used in the auction process, as explained below. 

At step 1210, auction engine server A1250 receives buyer's RFO 10 and her 
priorities 20 from buyer web server A500. 

At step 1220, auction engine server A1250 queries seller rules database A1240, 
and obtains business rules from those affiliated sellers that could potentially satisfy RFO 
10. In addition, third party information can be requested from third party database server 
A1280. For example, ratings information from a third party service (e.g., Consumer 
Reports) can be obtained if the buyer has limited her choices to only those products or 
services that have received a favorable review from such a rating service. Furthermore, 
information from past users of the present invention can be obtained from buyer database 
A1220. For example, a list of products and services that have received fewer than 20 
complaints from previous buyers using the Auctioneer can be obtained if the buyer has 
limited her choices to only those products or services that have not generated complaints 
by previous buyers. Simplified embodiments of the present invention need not include all 
of the various forms of information. Alternatively, auction engine A1250 can just obtain 
the business rules of sellers who satisfy all restrictions imposed by the buyer. Auction 
engine A1250 may also receive constraints imposed by the buyer on participating sellers, 
as specified in step 200, or limitations on bidders and auction outcomes, as specified in 
step 1180. Those steps are, however, not necessary. In another embodiment, the 
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restrictions may be applied by buyer web server A500 after adjusted offers 50 have been 
generated, for example at step 1300. 

At step 1230, the auction engine server A1250 retrieves the auction rules 
previously stored on the auction engine server A1250 by the Auctioneer service provider. 
Alternatively, the auction engine server A1250 can receive auction rules specified by the 
buyer from buyer web server A500. 

At step 1240, initial offers 40 are evaluated according to buyer's priorities 20 and 
a best initial offer is determined. The evaluation may involve weighting initial offers 40 
by linear weights constructed from buyer's priorities 20. Many other weighting 
techniques are admissible, however, such as non-linear weighting, and need not be 
described in detail here. 

At step 1250 an adjustment of seller offers is performed. Seller business rules 60 
are used to modify initial offers 40, or adjusted offers 50 made in a previous round. 
Seller business rules 60 can optionally respond based on information about the seller 
offers from the previous round. More thorough specification of seller business rules 60 is 
discussed below, with respect to FIGS. 29 - 30. 

At step 1260, adjusted offers 50 of the present round are evaluated. In the 
preferred embodiment, the evaluation is identical to that in step 1240. In alternative 
embodiments, however, it can be different. The evaluation may be used, for instance, to 
determine whether a seller's adjusted offer 50 is admissible. The criteria for admissibility 
of adjusted offer 50 are part of the auction rules, and can be very general. 

At step 1270, the status of the auction is compared with auction rules obtained in 
step 1230. If auction rules indicate the auction has not reached an end, it continues to 
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loop. For example, an auction that ends when no seller makes an improving offer may 
loop several times. 

At step 1275, value-added product or services can optionally be added to 
affiliated or unaffiliated sellers' offers. 

At step 1280, the process on the auction engine server terminates, with final 
adjusted offers 50 being transmitted to buyer web server A500. 

FIGS. 29 and 30 describe the process by which the seller creates and stores his 
business rules for the auction and obtains information, or analysis of information, 
generated by the present invention. It is assumed that the seller had established an 
Internet connection with seller web server A1000 , through seller interface All 00. Any 
computer capable of running Internet browser software can be used to establish this 
connection. 

At step 2000, the seller signs in to seller web server A1000 using seller interface 
A1100. The process of signing in involves the seller supplying any valid identification to 
access his account on seller rules database server A1240. The account on seller rules 
database server A1240 had been previously created by the maintenance staff of the 
System, based on an affiliation agreement with the seller. The agreement can, for 
example, be reached using mail, email, fax, Internet form subscription, or any other 
means of communication capable of supporting legally binding agreements. 

For cases in which the affiliation agreement is reached over the Internet, the seller 
may be presented with forms similar to U2000 (TIG. 50) , U2100 (FIG. 51), and U2200 
(FIG. 52V Form U2000 (FIG. 50) is an exemplary overview with links to sections 
discussing the rights and responsibilities accepted by the seller and the entity running the 
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present invention. Form U2100 (FIG. 51) illustrates possible types of affiliation. As 
mentioned in the "Product and Pricing" section of the Background, the present invention 
generates proprietary information. Different types of affiliation grant access rights to 
different bundles of proprietary information. Form U2200 (FIG. 52) succinctly 
summarizes exemplary types of information available under each type of affiliation. In a 
simpler embodiment of the present invention, all sellers could have identical access rights 
to the information. 

At step 2100, the seller chooses whether to view information generated, or 
mediated by the present invention. All affiliated sellers have access to auction results, 
such as that described as near-perfect information in the Background of the Invention. 
The information may range from that which is also readily available from other parties, to 
information that can be, in principle, obtained in the absence of the present invention (e.g. 
buyers' needs, or priorities), to detailed information that is only generated by the present 
invention, listed, for instance, in the right column of form U2200 (FIG. 52) . 

At step 2200, the seller specifies the information to view, in a suitable form 
displayed on seller's monitor All 15. This may include the area of products or services, 
the type of information, like RFOs 10, or auction results 50, the time period, and other 
constraints on requested records. Seller web server A1000 automatically compares the 
seller's request against his affiliation agreement obtained from seller rules database 
server A1240, and invalidates the request if the seller's affiliation agreement prohibits 
access to the requested information. At step 2300, seller web server A1000 searches 
buyer database server A1220, or third party databases A1280 and returns results as rules 
analysis 90 to the seller interface A1100. Forms like U3000 (FIG. 55) , U3100 (FIG. 56) , 
U3200 (FIG. 57) , U3400 (FIG. 58) or U3500 (FIG. 59) can be used to display 
information on individual transactions that occurred within the present invention. 
Exemplary forms U3000 (FIG. 55) and U3100 (FIG. 56) pertain to buyer's information. 
Some of the buyer's information may only be accessed with the buyer's permission, e.g., 
in exchange for buyer loyalty program incentives (like frequent flier points). Forms 
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U3200 (FIG. 57) and U3400 (FIG. 58) pertain to records of actual offers generated by the 
present invention, while form U3500 (FIG. 59) displays the terms of the offer eventually 
accepted by the buyer. Form U3600 (FIG. 60) displays aggregate information about and 
analysis of auctions occurring during a certain time interval. 

At step 2400, the seller can decide to use his business rules 60 in a simulated 
environment, giving him the opportunity to test them prior to committing to use them. 
Using a simulated environment helps the seller discover whether his rules perform as 
intended. 

At step 2500, the seller enters his business rules 60 into forms like U2300 (FIG. 
53) or U2400 (FIG. 54) . Form U2300 (FIG. 53) represents only an example of the way 
business rules 60 can be specified. These rules could also be driven by an electronic 
interface to another computer located on the seller's site which contains seller's own 
proprietary rule based system. Different sets of specifications can be allowed in different 
categories of products. Business rules 60 are sent by seller interface All 00 to seller web 
server A1000 and passed to seller rules database server A1240, however, they are marked 
"simulation-only" as they do not represent a binding commitment on the part of the 
seller. 

At step 2600, a simulation is run inside core network A1200. In one embodiment, 
auction engine A1250 obtains the last n RFOs 10 and priorities 20 from buyer database 
server A1220 falling within the category to which the business rules apply. Auction 
engine A1250 then runs n auctions employing the seller's rules 60 against other sellers' 
rules. In a different embodiment, auction rules 60 are treated by auction engine A1250 as 
valid rules, except the offers generated by them are not made visible to the buyer within 
returned adjusted offers 50. After the simulation ends, seller rule 60 is invalidated by 
seller rule database server A1240. 
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At step 2700, auction engine server A1250 sends simulation results 70 to seller 
web server A1000 for further processing. Seller web server A1000 passes results 70, or 
their analysis to seller interface All 00 where they are displayed on seller video monitor 
All 15. The results may show basic aggregate information about how the sellers 
simulated rules compared to other sellers' rules in all dimensions, as in form U3600 (FIG. 
60) , or information on how many auctions were won, and what were the priorities 
profiles to which the simulated rule most appealed. 

At step 2800, the seller can continue to experiment with his business rules in the 
simulation by changing the parameters. 

At step 2900, the seller can modify his business rules 60 that he uses in actual (not 
simulated) auctions. 

At step 3000, the affiliated seller enters or modifies seller business rules 60 in 
form U2300 (FIG. 53) , in much the same way as in the simulated environment. The seller 
can adopt business rules that produced favorable results for him in a simulation. 
However, the modified rules do not have to be based on simulation results. 

At step 3100, the seller decides to make new seller business rules 60 legally 
binding. 

At step 3200, seller business rules 60 are sent to seller web server A1000 and 
permanently stored within seller rules database A1240 of core network A1200. 

The various embodiments described above should be considered as merely 
illustrative of the present invention and not in limitation thereof. They are not intended to 
be exhaustive or to limit the invention to the forms disclosed. Those skilled in the art will 
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readily appreciate that still other variations and modifications may be practiced without 
departing from the general spirit of the invention set forth herein. Therefore, it is 
intended that the present invention be defined by the claims which follow: 
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In the claims: 



I. Please cancel claims 71, 72, and 73. 

II. Please substitute rewritten claims 2, 3, 83, 95, 102, 105, 109, 110, and 
111 for the pending claims with the same numbers as follows: 

2. (Once Amended) [The method of claim 1, further] A fully automated method of 
facilitating an electronic auction between a prospective buyer and a plurality of 
prospective sellers with near perfect information, comprising the steps of: 

a) inputting into a computer a buyer's request for information about products 
or services; 

b) finding information in response to the request for information; 

c} communicating at least part of the information found to the buyer; 

d) inputting into the computer a buyer's request for an offer; 

e) communicating the request for an offer to at least two of the sellers; 

f) receiving offers, including terms of sale in response to the request for an 
offer, from at least two of the sellers; 

g) automatically generating rating information about seller offers based on a 
plurality of predetermined criteria; 

h) communicating information regarding at least some of the seller offers to 
at least one other seller; 

i) receiving an adjusted offer from at least one of the sellers during a 
specified auction period ; and 

j) communicating information regarding at least some of the seller offers and 
at least part of the rating information [found] to the buyer. 

3. (Once Amended) The method of claim 2, wherein said request for an offer is 
inputted using an electronic template. 
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83. (Once Amended) [The method of claim 1, further comprising] A fully automated 
method of facilitating an electronic auction between a prospective buyer and a 
plurality of prospective sellers with near perfect information, comprising the steps 
o£ 

a) inputting into a computer a buyer's request for an offer; 

b) communicating the request for an offer to at least two of the sellers; 

c) receiving offers, including terms of sale in response to the request for an 
offer, from at least two of the sellers; 

d) automatically generating rating information about seller offers based on a 
plurality of predetermined criteria; 

e) communicating information regarding at least some of the seller offers to 
at least one other seller; 

0 receiving an adjusted offer from at least one of the sellers during a 
specified auction period; ^ 

g) communicating information regarding at least some of the seller offers and 
at least part of the rating information to the buyer; and 

h) selling information about the auction. 

95. (Once Amended) [The method of claim 1, further comprising] A fully automated 
method of facilitating an electronic auction between a prospective buyer and a 
plurality of prospective sellers with near perfect information, comprising the steps 
of: 

a) inputting into a computer a buyer's request for an offer; 

b) communicating the request for an offer to at least two of the sellers; 

c) receiving offers, including terms of sale in response to the request for an 
offer, from at least two of the sellers; 

d) automatically generating rating information about seller offers based on a 
plurality of predetermined criteria; 

e) communicating information regarding at least some of the seller offers to 
at least one other seller; 
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f) receiving an adjusted offer from at least one of the sellers during a 
specified auction period; 

g) communicating information regarding at least some of the seller offers and 
at least part of the rating information to the buyer; and 

h) selling information about the buyer. 

102. (Once Amended) The method of claim 1, further comprising completing [the] an 
electronic transaction at an electronic site that was also used for the buyer's 
auction. 

105. (Once Amended) The method of claim 1, further comprising completing [the] an 
electronic transaction at an electronic site representing one of the sellers. 

109. (Once Amended) The method of claim 1, wherein the step of communicating 
information regarding at least some of the seller offers [and at least part of the 
rating information] to at least one [of the] other seller[s] occurs before the step of 
receiving an adjusted offer. 

110. (Once Amended) The method of claim 1, wherein the step of communicating 
information regarding at least some of the seller offers [and at least part of the 
rating information] to at least one [of the] other seller[s] occurs after the step of 
receiving an adjusted offer. 

111. (Once Amended) The method of claim 1, wherein the step of communicating 
information regarding at least some of the seller offers [and at least part of the 
rating information] to at least one [of the] other seller[s] occurs both before and 
after the step of receiving an adjusted offer. 



90679.03-Palo Alto Server 1 A - MSW 



46 



REMARKS 



A. Objection to the disclosure 

The Detailed Description has been amended to link Figures 31-60 with the 
corresponding user interfaces U100 - U3600 by putting the figure number after the user 
interface number in the Detailed Description, e.g., "U100 (FIG. 31)." Figures 31-60 have 
been described in the Brief Description of the Figures to show their pertinence to the 
invention. Support for these amendments is found in Figures 31-60 and pages 75-96 of 
the Detailed Description. No new matter has been added. 

B. Objections to claims 2-6, 34-36 and 83-100 under 37 CFR 1.75(c) 

In a phone call with the Examiner on November 21, 2002, Examiner Patel stated 
that the inclusion of claims 34-36 in this objection was a typographical error. Thus, 
claims 34-36 remain unchanged because there was no objection under 37 CFR 1.75(c) to 
claims 34-36. 

Applicants respectfully disagree with the Examiner's objection that claims 2-6 
and 83-100 do not further limit parent claim 1 because these claims have no relationship 
to the invention recited in claim 1 . Applicants disagree because the method recited in 
claim 1 concerns more than just the auction period itself. Rather, the method recited in 
claim 1 is a set of steps that facilitates an auction with near perfect information. 
Dependent claims 2-6 and 83-100 list additional steps that further limit the method of 
facilitating an auction with near perfect information recited in claim 1 . 

Nevertheless, Applicants have rewritten claims 2, 83, and 95 in independent form 
because the Examiner has stated that this will remove the objection (" Applicant is 
required to cancel the claim(s), or . . . rewrite the claim(s) in independent form ." page 2 
of the Office Action, emphasis in original). No new matter has been added. These are 
purely cosmetic changes that do not narrow the scope of these claims. 
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C. Rejection of claims 34-36, 38-46, 52-56, 71-75, 102-105, and 109-111 under 35 
U.S.C. 112 1f2 



In a phone call with the Examiner on November 21, 2002, Examiner Patel 
concluded that there was, in fact, proper antecedent basis for claims 34-36, 38-46, 52-56, 
and 74-75. Thus, these claims remain unchanged because there is no longer a rejection 
under 35 U.S.C. 1 12 1f2 of these claims. 

Claims 71-73 have been cancelled. 

Claims 102, 105, and 109-1 1 1 have been amended to overcome the rejection 
under 35 U.S.C. 112 1f2 of claims 102-105 and 109-1 1 1. No new matter has been added. 

D. Rejection of claims 1, 7-15, 18-29, 30-33, 37-39, 47-51, 53, 62-70, 74, 76-82, 

101 and 112 under 35 U.S.C. 103(a) as being unpatentable over Alaia in view 
of Gindlesperger 

In a telephone interview on November 12, 2002, we explained to Examiner Patel 
that claim element 1(d), i.e., 

d) automatically generating rating information about 
seller offers based on a plurality of predetermined 
criteria; 

is not taught by Gindlesperger. 

Instead, Gindlesperger concerns a system for deciding which sellers receive RFQs 
to begin with, i.e., the system prequalifies sellers. Sellers' offers (bids) are not rated 
based on a plurality of criteria in Gindlesperger. Rather, the lowest bid wins. 

These facts are explained at several places in Gindlesperger, including 1) the 
Abstract; 2) column 5, lines 1-25; and 3) Figure 1, steps 12 -22: 
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[A] vendor's invitation to bid is transmitted to the vendors from among 
those approved by the buyer associated with the buyer's invitation for bid 
having a vendor capability data meeting the calculated vendor 
requirements. Responding bids from the vendors are input into the 
database and ranked in order of price . The lowest price bid is identified . . . 
Abstract 

. . . receiving at the PrintProSys SM server a buyer's invitation- for-bid 
describing a customized print or other information product or service that 
the buyer wishes to procure or obtain bids for, calculating or extracting a 
vendor selection criteria data from the buyer's invitation-for-bid, the 
vendor selection criteria data defining the values that a vendor's capability 
data must meet to qualify for, and to receive, a vendor's invitation-for-bid 
requesting a bid response corresponding to the buyer's invitation-for-bid. 

The method of the present invention then compares and correlates the 
vendor selection criteria data to the vendor capability data field of each vendor 
data record in the buyer's vendor pool database. The PrintProSys SM server then 
transmits a vendor's invitation-for-bid data to each vendor in the buyer's vendor 
pool whose vendor capability data field meets the vendor selection criteria data 
extracted from the buyer's invitation-for-bid data. Next, the PrintProSys SM server 
receives a plurality of responding bid data, each being from a corresponding one 
of the plurality of vendors to whom a vendor invitation-for-bid data was 
transmitted, and each representing the transmitting vendor's price for the 
particular print information goods or services requested. The PrintProSys SM server 
then selects the responding bid data having the lowest represented vendor price . . . 
column 5, lines 1-25 

DETECT LOW BID Bi . . . Figure 1, step 20 

Thus, because Gindlesperger fails to teach claim element 1(d), Claim 1 (and all of 
its dependent claims) cannot be made obvious by Alaia in view of Gindlesperger. 

In the phone interview, the Examiner agreed that Gindlesperger does not teach 
claim element 1(d) for the reasons just described. Thus, the Examiner agreed to 
withdraw all of the present 103(a) rejections because all of these rejections rely on 
Gindlesperger to teach claim element 1(d). The Examiner indicated, however, that he 
may make new 103(a) rejections based on prior art other than Gindlesperger in another 
non- final office action. 
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E. Rejection of claims 2-6, 34-36, 107, and 108 under 35 U.S.C. 103(a) as being 
unpatentable over Alaia in view of Gindlesperger and Walker 



As explained in Remarks Section D. above, the Examiner has agreed to withdraw 
all of the present 103(a) rejections. 

F. Rejection of claims 16 and 17 under 35 U.S.C. 103(a) as being unpatentable 
over Alaia in view of Gindlesperger and Chen 

As explained in Remarks Section D. above, the Examiner has agreed to withdraw 
all of the present 103(a) rejections. 

G. Rejection of claims 57-61 and 106 under 35 U.S.C. 103(a) as being 
unpatentable over Alaia in view of Gindlesperger and Mori 

As explained in Remarks Section D. above, the Examiner has agreed to withdraw 
all of the present 103(a) rejections. 



In light of the foregoing, the objections and rejections in the Office Action dated 
July 5, 2002 are believed to be traversed, and Applicants request that the objections and 
rejections be withdrawn and the claims be passed to allowance. 

If the Examiner believes a discussion of the above would be useful, he is invited 
to call the Applicants' attorney, Dr. Robert Beyers, at (650) 470-4624. 



CONCLUSION 



Respectfully submitted, 



Date: December 5, 2002 




Robert Beyers, Ph.D. 
Reg. No. 46,552 



SKADDEN, ARPS, SLATE, MEAGHER & FLOM LLP 
525 University Avenue 
Palo Alto, California 94301 
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